Skip Headers

Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# Migrating the Flash Recovery Area to ASM

This section describes procedures to use if you already have backups on disk in non-ASM disk storage and you want to start using ASM to store your flash recovery area. You must set the initialization parameters related to the flash recovery area to refer to the ASM disk location. Then you can migrate existing backups, online logs, to the new ASM flash recovery area

- Setting Initialization Parameters for Flash Recovery Area in ASM

- Migrating the Control File to an ASM Flash Recovery Area

- Migrating Existing Backups to ASM Flash Recovery Area

## Setting Initialization Parameters for Flash Recovery Area in ASM

The following process moves the flash recovery area from non-ASM disk storage to an ASM disk group named `+FRA`.

Note: If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform this step. Before changing the location of the flash recovery area, you should drop any guaranteed restore points. Flashback logs used to support guaranteed restore points are stored in the flash recovery area.

Specify the location of the flash recovery area by setting `DB_RECOVERY_FILE_DEST` and `DB_RECOVERY_FILE_DEST_SIZE`. (For this example, assume the intended size of the flash recovery area is 100 gigabytes.) If you are using an SPFILE then in SQL*Plus enter the following commands:

    SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=100G SID='*';
    SQL> alter system set DB_RECOVERY_FILE_DEST='+FRA' SID='*';

If you are using a PFILE, then shut down the database, edit the above parameters in the PFILE with the new values for `DB_RECOVERY_FILE_DEST` and `DB_RECOVERY_FILE_DEST_SIZE` and restart the instance.

## Migrating the Control File to an ASM Flash Recovery Area

Note: If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform this step.

In this example, it is assumed that you have already set the initialization parameters for a flash recovery area in ASM storage, using the process in "Setting Initialization Parameters for Flash Recovery Area in ASM". It is also assumed that one control file is already stored in `+DISK/ct1.f`, the other in non-ASM storage. The goal is to move the non-ASM control file to the flash recovery area and store it as `+FRA/ct2.f`.

- In SQL*Plus, bring the database to NOMOUNT:

      SQL> SHUTDOWN IMMEDIATE;
      SQL> STARTUP NOMOUNT;

  Change the `CONTROL_FILES` initialization parameter to refer to the new location. If you are using an SPFILE, use the following command:

      SQL> alter system set control_files='+DISK/ct1.f','+FRA/ct2.f' scope=spfile sid='*';

  If using a PFILE, edit the PFILE with the new for the CONTROL_FILES initialization parameter.

  Shut down and startup in NOMOUNT again, so that the changed CONTROL_FILES parameter takes effect.

- Then, use RMAN to actually create the new control files in ASM.

      RMAN> restore controlfile from '+DISK/ct1.f';
      RMAN> alter database mount;

- If you were using flashback logging before to support flashback database, you can re-enable it now. For example:

      SQL> ALTER DATABASE FLASHBACK ON;

Note: If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform this step.

The following procedure changes the database configuration so that the flash recovery area is used for all future backups.

1. The first step is to change the initialization parameters for the database to store the flash recovery area in ASM, as described in Setting Initialization Parameters for Flash Recovery Area in ASM.

2. If this database is a primary database and your online logs, control file or archived redo logs are in the flash recovery area, then perform a consistent shutdown of your database. For example:

       SQL> SHUTDOWN IMMEDIATE

   If this database is a standby database and your standby online logs, control file, or archive logs are in recovery area, then stop managed recovery mode and shut down the database.

3. Modify the initialization parameter file of the target database as follows:

   - Set `DB_RECOVERY_FILE_DEST` to the desired ASM disk group.

   - Modify `DB_RECOVERY_FILE_DEST_SIZE` if you need to change the size of the flash recovery area.

4. If you shut down the database in step 2, then bring the database to a NOMOUNT state. For example:

       RMAN> STARTUP NOMOUNT

   If the old flash recovery area has copy of the current control file, then restore control file from the old `DB_RECOVERY_FILE_DEST` and mount the database again.

       RMAN> RESTORE CONTROLFILE FROM 'filename_of_old_control_file';
       RMAN> ALTER DATABASE MOUNT;

5. The next step is to migrate the control file from the old flash recovery area to the new flash recovery area. In this example, one control file is stored as `+DISK/ct1.f`, the other as `+FRA/ct2.f`.

   In SQL*Plus, change the `CONTROL_FILES` initialization parameter using the following command:

       SQL> alter system set control_files='+DISK/ct1.f','+FRA/ct2.f' scope=spfile sid='*';

6. If you were using flashback logging before to support flashback database, you can re-enable it now. For example:

       SQL> ALTER DATABASE FLASHBACK ON;

At this point, all future files that are directed to the flash recovery area are created in the new ASM flash recovery area location.

## Changing Flashback Log Location to ASM Flash Recovery Area

Note: If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform this step.

In this example, it is assumed that you have already set the initialization parameters for a flash recovery area in ASM storage, using the process in "Setting Initialization Parameters for Flash Recovery Area in ASM".

Because the actual flashback logs cannot be migrated, the only step required to move the location of flashback logs to the new ASM flash recovery area is to disable and then enable flashback logging. After a clean shutdown, mount the database and run the following commands in SQL*Plus:

    SQL> ALTER DATABASE FLASHBACK OFF;
    SQL> ALTER DATABASE FLASHBACK ON;

Future flashback logs will be created in the new flash recovery area. The old flashback logs are automatically deleted from non-ASM storage.

## Migrating Online Logs to ASM Flash Recovery Area

Note: If you have already migrated all of these files to ASM storage using the procedure in "Disk-Based Migration of a Database to ASM" you do not need to perform this step.

In this example, it is assumed that you have already set the initialization parameters for a flash recovery area in ASM storage, using the process in "Setting Initialization Parameters for Flash Recovery Area in ASM".

For a primary database, migrating the online logs is performed by adding new log group members in ASM, and then dropping the old members. The database must be open to perform this task.

The easiest way to perform this step is to use a PL/SQL script based upon the one in "Migrating Online Logs of Primary Database to ASM". However, change the script so that it does not specify the disk group name.

For example, change the code that creates the online logs from:

    stmt := 'alter database add logfile thread ' ||
                     rlcRec.thr || ' ''+DISK'' size ' ||
                     rlcRec.bytes_k || 'K';

to:

    stmt := 'alter database add  logfile thread ' ||
                     rlcRec.thr || ' size ' ||
                     rlcRec.bytes_k || 'K';

Also change the code that creates the standby logs from:

    stmt := 'alter database add standby logfile thread ' ||
                     rlcRec.thr || ' ''+DISK'' size ' ||
                     rlcRec.bytes_k || 'K';

to the following code:

    stmt := 'alter database add standby logfile thread ' ||
                     rlcRec.thr || ' size ' ||
                     rlcRec.bytes_k || 'K';

For a standby database, you can follow similar steps to the script to drop the old standby redo logs and add new ones in the `+FRA` disk group, but the online redo logs cannot be migrated until the database is opened as a primary.

Once you have run your script, the migration of online logs is complete.

## Migrating Existing Backups to ASM Flash Recovery Area

In this example, it is assumed that you have already set the initialization parameters for a flash recovery area in ASM storage, using the process in "Setting Initialization Parameters for Flash Recovery Area in ASM".

Note: After you configure the database to change the location of the flash recovery area, backups created in the old flash recovery area location remain in their old location, still count against the total disk quota of the flash recovery area, are deleted from the old flash recovery area as space is required for other files, and can still be managed by RMAN and used in RMAN recovery operations. There is no need to move existing backups to the new ASM flash recovery area, unless you need the disk space used by those files for other purposes. If you do need to free the space taken up by leftover non-ASM flash recovery area files, your options include backing them up to tape (for example, by using `BACKUP` `RECOVERY` `AREA` `DELETE` `INPUT`) or moving the backups from the old flash recovery area location to the new one, as described in this section.

To back up the existing archived redo log files to the new flash recovery area, use this command:

    RMAN> BACKUP AS COPY ARCHIVELOG ALL DELETE INPUT;

To move backup sets to the new flash recovery area, use this command:

    RMAN> BACKUP DEVICE TYPE DISK BACKUPSET ALL DELETE INPUT;

To move all datafile copies to the new flash recovery area location, use this command:

    RMAN> BACKUP AS COPY DATAFILECOPY ALL DELETE INPUT;

At this point, all backups have been moved from the old flash recovery area to the new one.